System, method and computer program product for protecting software via continuous anti-tampering and obfuscation transforms

ABSTRACT

Method, system and computer program product for applying existing anti-tampering and obfuscation technique to virtual machine technology and offers several distinct advantages. The anti-tampering and obfuscation transforms can be applied continuously to prevent adversaries from gaining information about the program through emulation or dynamic analysis. In addition, the encryption can be used to prevent hackers from gaining information using static attacks. The use of a virtual machine also allows for low overhead execution of the obfuscated binaries as well as finer adjustment of the amount of overhead that can be tolerated. In addition, more protection can be applied to specific portions of the application that can tolerate slowdown. The incorporation of a virtual machine also makes it easy to extend the technology to integrate new developments and resistance mechanisms, leading to less development time, increased savings, and quicker deployment.

RELATED APPLICATIONS

The present invention claims priority from U.S. Provisional ApplicationSer. No. 61/016,009, filed Dec. 21, 2007, entitled “System and RelatedMethod for Protecting Software Via Continuous Anti-Tampering andObfuscation Transforms;” of which the disclosure is hereby incorporatedby reference herein in its entirety.

GOVERNMENT SUPPORT

Work described herein was supported by Federal Grant No. CNS-0716446,awarded by the NSF. The Government has certain rights in the invention.

BACKGROUND OF THE INVENTION

Software programmers want the ability to make their computer softwareprotected from undesired change. Such changes can be manual, such as amalicious user bypassing a licensing check in commercial software, orautomatic, such as a virus modifying a binary to include a copy of thevirus. To verify that it has not been modified, software attempts tomonitor its own code, with execution changing when a modification to thecode is detected (anti-tampering). To thwart a malicious user fromlocating and disabling self-checking code, code is made difficult tounderstand, and self-checking codes are hidden within the rest of theapplication code (obfuscation). Unfortunately, malicious attackerscontinue to thwart such checks using a variety of information gatheredfrom the dynamic execution of the program.

The issue of protecting software from unauthorized tampering is acritical problem in modern software deployment. Billions of dollars arelost in revenue each year due to the efforts of malicious hackers andsoftware pirates. For example, malicious users may modify software tobypass a licensing check in commercial software or alter programs toinclude a copy of a computer virus. Anti-tampering methods are also ofgreat importance in the growing area of digital rights management, wheretampering results in the loss of significant royalties and license fees.

One popular method of protecting a program from modification is codeobfuscation. Code obfuscation involves modifying computer code so thatit is more difficult to understand. This then makes it more difficultfor malicious hackers to figure out what parts of a program to modify.While a powerful tool in the fight to make software more secure,existing obfuscation techniques unfortunately possess several drawbacks.Much of the work in this area only involves making it more difficult toperform “static analysis” of programs. In other words, many techniquesonly deter knowledge of source code or object code but not knowledge ofexecuting code (“dynamic analysis”), which can often be gained bypiecing together the information from several different runs of theprogram. Many obfuscation strategies also involve extremely highoverhead, which may be unacceptable for many people and prevent adoptionof the security measure. Other obfuscation strategies require the use ofspecial hardware or fail to present complete and implementablesolutions.

Previous work has, but not limited thereto, a variety of major drawbacksas discussed below.

Much work strives only to make the program hard to statically analyze[See 21, 33]. For example, an opaque predicate may be hard to analyzestatically, but several runs of the program in a simulator can determinewhich branches are highly biased. That information can be fed into astatic disassembler to identify the start of basic blocks. Also, thatsame run of the simulator can help reveal (the dynamically executedportions of) the control flow graph. Combining information from severalruns of the program can yield a highly accurate representation of theinstructions in a program, the opaque predicates, and the control flowgraph.

Other work requires special hardware [See 28, 30, 24]. For example, ahardware device that stores a decryption key or a processor that onlyexecutes encrypted instructions can be used to guarantee that onlyprograms that were generated with a proper encryption key can run.Unfortunately, specialized hardware may be expensive and not generallyor widely available. Furthermore, users may reject hardware that isincapable of running a wide variety of programs.

Some previously proposed techniques have extremely high overhead [See2]. In fact, some previous work provides such an unreasonable executionoverhead that an overhead measurement is not even suggested. Realistic,usable solutions must provide minimal overhead or people will beunwilling to adopt the security measures.

Yet other work provides a threat model that does not meet thetamper-resistance needs of modern hardware, or provides only a partialor impractical solution [See 16, 18, 27]. Some previous techniques evenassume that an optimal algorithm for performing a checksum calculationcan be computed, that the optimal algorithm runs on a known hardwareconfiguration (and even a pre-calculated clock rate) and that the resultcan transmitted over an unmonitored network within bounded time!

Thus, there is a continuing need for better ways to secure software,systems and content by providing a mechanism for the protection ofsoftware from tampering and reverse engineering.

SUMMARY OF THE INVENTION

An aspect of various embodiments of the present invention provides,among other things, a mechanism for protection of software fromtampering and reverse engineering. Efficient software dynamictranslation is used to continually provide dynamic tamper-resistance andobfuscation. To prevent modifications to the pre-translated softwareversion, encryption is used. Self-checking codes are hidden within theencrypted code, which help protect both the original program code andthe software dynamic translator's program code. The dynamic translatorcaches blocks of code from the original application in a code cache. Toprotect these cached blocks, the translator dynamically appliesanti-tampering and obfuscation techniques. The cache is flushedperiodically and randomized anti-tampering and obfuscation techniquesare re-applied to protect dynamic information from being leaked by theexecution of the program.

An aspect of an embodiment of the present invention utilizes recenttrends that enable high-speed translation of program code, and the everincreasing computing power that is available in modern computer systems.An approach uses a portion of the CPU time to dynamically performanti-tampering and obfuscating transformations.

An aspect of various embodiments of the present invention is that it maybe utilized for a number of products, applications, implementations, andservices. For instance, any vendor that produces software may beinterested in using or implementing this technology (i.e., method,system, and/or computer program product). Examples may include, but notlimited thereto, the following: Microsoft, including their Windows andOffice lines of software; Adobe, including their Acrobat products, etc.;Sun Microsystems, including Solaris products, etc.; and Cloakwareproducts and virtual machine.

An aspect of various embodiments of the present invention is applicableto “vaccinating” a computer system against viruses. Consequently majorvirus/worm/spyware/adware detection companies may be interested,including Symantec or the like.

Furthermore, malicious software detection programs have a direct need toavoid modification/disablement by a virus.

Digital rights management is an important aspect of the proposedtechnology as well. By protecting a media player, various embodiments ofthe present invention can be used to manage a key hidden within themedia player, thus protecting the media itself.

Medical applications may be a particularly useful application area forvarious embodiments of the present invention. Especially, for example,as semi-robotic machines take over surgical tasks, it is important toknow that a system is unmodified. Similarly, space exploration couldbenefit by detecting failure/modification of a sub-system with such amechanism.

Military applications may benefit from the technology of the variousembodiments of the present invention. Broadly applying such systems maythwart an “insider attack” on a system as the insider may not be able totamper with the software.

Virtual machine technology applied to anti-tampering and obfuscationtechnology provide a stronger mechanism for anti-tampering andobfuscation than any previous technology. Accordingly, an aspect ofvarious embodiments of the present invention may provide a number ofadvantages, such as but not limited thereto, the following:

-   -   Continuous application of anti-tampering and obfuscation        transforms prevent an adversary from gaining information by        using emulation.    -   Encryption prevents the adversary from gaining information about        the application using static attacks.    -   Software dynamic translation technology allows for low overhead        execution of obfuscated binaries.

Checksumming codes hidden within the encrypted portion ensure that thevirtual machine itself is not modified.

-   -   Allows software producer to tune the amount of protection based        on the amount of overhead which can be tolerated.    -   More protection can be applied only to portions of the        application that can tolerate slowdown.    -   Protection is complementary to other forms of protection. For        example, if new mechanisms for hiding keys in applications are        discovered, the virtual machine technology can provide        continuous obfuscation and tamper resistance for the new        mechanism.

Aspects of various embodiments of the present invention may provide, butnot limited thereto, the following:

-   -   ability to prevent users from making small, meaningful changes        to computer programs, such as overriding copy protection and        timeouts in demonstration software and other software types.    -   protect computer software against reverse engineering which        might be used to identify valuable intellectual property        contained within a software algorithm or model. In hardware        design, for example, vendors of application specific integrated        circuit (ASIC) cell libraries often provide precise software        models corresponding to the hardware, so that users can perform        accurate system simulations. Because such a disclosure usually        provides sufficient detail to reveal the actual cell design, it        is desirable aspect of the present invention to protect the        content of the software model.    -   hide secret keys in software programs and transmissions, so that        software programs can sign, encrypt and decrypt transactions and        other software modules. At the same time, these secret keys        stays protected against being leaked.

An aspect of an embodiment of the present invention provides as method,system or computer Program product for applying existing anti-tamperingand obfuscation techniques to virtual machine technology and offersseveral distinct advantages. The anti-tampering and obfuscationtransforms can be applied continuously to prevent adversaries fromgaining information about the program through emulation or dynamicanalysis. In addition, the encryption of an embodiment of the presentinvention can be used to prevent hackers from gaining information usingstatic attacks. The use of a virtual machine also allows for lowoverhead execution of the obfuscated binaries as well as fineradjustment of the amount of overhead that can be tolerated. In addition,more protection can be applied to specific portions of the applicationthat can tolerate slowdown. The incorporation of a virtual machine alsomakes it easy to extend the technology to integrate new developments andresistance mechanisms, leading to less development time, increasedsavings, and quicker deployment.

An aspect of an embodiment or partial embodiment of the presentinvention (or combinations of various embodiments in whole or in part ofthe present invention) may comprise a computer method of increasing thetamper-resistance and/or obscurity of computer software code. The methodmay comprise preparing the computer software code for execution in adesignated execution environment for making it difficult to execute thecomputer software code independently from the designated executionenvironment. The method may further comprise preparing the executionenvironment so that it impedes execution of computer software code inthe execution environment except for a designated computer softwarecode. The method may further include applying execution transformationsduring execution of a computer software code to improve tamperresistance and/or obscurity.

An aspect of an embodiment or partial embodiment of the presentinvention (or combinations of various embodiments in whole or in part ofthe present invention) may comprise a computer method for preparing theexecution environment so that it impedes execution of computer softwarecode in the execution environment except for a designated computersoftware code. The method further include applying executiontransformations during execution of a computer software code to improvetamper resistance and/or obscurity.

An aspect of an embodiment or partial embodiment of the presentinvention (or combinations of various embodiments in whole or in part ofthe present invention) may comprise a computer method for increasing thetamper-resistance and/or obscurity of computer software code. The methodmay comprise applying execution transformations during execution of acomputer software code to improve tamper resistance and/or obscurity.The method may further include preparing the computer software code forexecution in a designated execution environment for making it difficultto execute the computer software code independently from the designatedexecution environment.

An aspect of an embodiment or partial embodiment of the presentinvention (or combinations of various embodiments in whole or in part ofthe present invention) may comprise a computer system of increasing thetamper-resistance and/or obscurity of computer software code. The systemmay comprise preparation means (or module, device, driver, engine,system, or hardware) for preparing the computer software code forexecution in a designated execution environment for making it difficultto execute the computer software code independently from the designatedexecution environment. The system may further comprise a preparationmeans (module, device, system, or hardware) for preparing the executionenvironment so that it impedes execution of computer software code inthe execution environment except for a designated computer softwarecode. The system may further include an application means (or module,device, driver, engine, system, or hardware) for applying executiontransformations during execution of a computer software code to improvetamper resistance and/or obscurity.

An aspect of an embodiment or partial embodiment of the presentinvention (or combinations of various embodiments in whole or in part ofthe present invention) may comprise a computer system of increasing thetamper-resistance and/or obscurity of computer software code. The systemmay comprise an execution transformer (or module, device, driver,engine, system, means, or hardware) for applying executiontransformations during execution of a computer software code to improvetamper resistance and/or obscurity. The system may further comprise apreparation means (or module, device, driver, engine, system, orhardware) for preparing the computer software code for execution in adesignated execution environment for making it difficult to execute thecomputer software code independently from the designated executionenvironment.

An aspect of an embodiment or partial embodiment of the presentinvention (or combinations of various embodiments in whole or in part ofthe present invention) may comprise a computer program productcomprising a computer useable medium having computer program logic forenabling at least one processor in a computer system to increase thetamper-resistance and/or obscurity of computer software code. Thecomputer logic comprising: preparing the computer software code forexecution in a designated execution environment for making it difficultto execute the computer software code independently from the designatedexecution environment. The computer program product may further comprisepreparing the execution environment so that it impedes execution ofcomputer software code in the execution environment except for adesignated computer software code. Further, the computer program productmay include applying execution transformations during execution of acomputer software code to improve tamper resistance and/or obscurity.

An aspect of an embodiment or partial embodiment of the presentinvention (or combinations of various embodiments in whole or in part ofthe present invention) may comprise a computer program productcomprising a computer useable medium having computer program logic forenabling at least one processor in a computer system to operate. Thecomputer logic may comprise preparing the execution environment so thatit impedes execution of computer software code in the executionenvironment except for a designated computer software code. The computerprogram product may further include applying execution transformationsduring execution of a computer software code to improve tamperresistance and/or obscurity.

An aspect of an embodiment or partial embodiment of the presentinvention (or combinations of various embodiments in whole or in part ofthe present invention) may comprise a computer program productcomprising a computer useable medium having computer program logic forenabling at least one processor in a computer system to increase thetamper-resistance and/or obscurity of computer software code. Thecomputer logic may comprise applying execution transformations duringexecution of a computer software code to improve tamper resistanceand/or obscurity. The computer program product may further includepreparing the computer software code for execution in a designatedexecution environment for making it difficult to execute the computersoftware code independently from the designated execution environment.

These and other objects, along with advantages and features of theinvention disclosed herein, will be made more apparent from thedescription, drawings and claims that follow.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are incorporated into and form a partof the instant specification, illustrate several aspects and embodimentsof the present invention and, together with the description herein, andserve to explain the principles of the invention. The drawings areprovided only for the purpose of illustrating select embodiments of theinvention and are not to be construed as limiting the invention.

FIGS. 1-16 provide a schematic block diagram for various embodiments ofthe present invention computer method or system for increasing thetamper-resistance and/or obscurity of computer software code or otherrelated.

FIGS. 17-32 pertains to specific exemplary (and non-limiting)embodiments as they may pertain to the approach illustrating the presentinvention computer method or system embodiments of FIG. 1-16,respectively.

FIGS. 33-35 pertain to an exemplary embodiment of the present inventioncomputer method or system (and related computer program product) as itpertains to increasing the tamper-resistance and/or obscurity ofcomputer software code and related. FIG. 33 provides a schematic blockdiagram of the Strata architecture with anti-tampering and obfuscationmodules, used to perform dynamic anti-tampering and obfuscation. FIG. 34provides a graphical representation of the amount of application code(as a percent of total application code) that materializes into the codecache as a function of time. Higher flushing intervals achieve lowercode visibility. FIG. 35 provides a graphical representation of theruntime overhead of Strata with code cache flushing. More frequentlyflushing causes higher overhead.

FIG. 36(A) is a block diagram of a processor-based system for use withan embodiment of the present invention.

FIG. 36(B) is a block diagram of a wireless device for use with oneembodiment of the present invention.

FIG. 37 is a schematic block diagram for a system or related method ofan embodiment of the present invention in whole or in part.

DETAILED DESCRIPTION OF THE INVENTION Prepare Computer Software Code

Referring to FIG. 2, there is provided a schematic block diagram of thecomputer method or system 10 (or related method or computer programproduct) for increasing the tamper-resistance and/or obscurity ofcomputer software code 14. The method or related system may comprisepreparing 18 the computer software code 14 for execution in a designatedexecution environment 26 for making it difficult to execute the computersoftware code 14 independently from the designated execution environment26.

In contrast, a previous approach may have allowed the execution of acomputer software code within a generic (i.e., undesignated) executionenvironment. Additionally, a previous approach may have defined a widerange of static obscurity and/or static tamper resistancetransformations (i.e., prior to run time or execution time). Whereas, anaspect of an embodiment of the present invention provides a method (orsystem or computer program product) for only allowing execution of acomputer software code within a specified (i.e., designated) executionenvironment. That is, the computer software code is inextricably boundto the designated execution environment. As an example, codes to verifyintegrity of the specified execution environment can be inserted in thecomputer software code, thereby increasing the obscurity of the computersoftware code and the binding the computer software code to thedesignated execution environment. For instance, an example of anapplication may involve, but not limited there to, a cell phone, wherebythe cell phone may have a Java VM as the execution environment. See, forexample, Tim Lindholm and Frank Yellin. The Java Virtual Machinespecification, second edition. Addison-Wesley, 1999, of which is herebyincorporated by reference herein in its entirety. And one may consider aJava game as a computer software code. An embodiment of the presentinvention provides a method (or system or computer program product) thatallows the insertion of checks into the Java game to verify the JavaVM's integrity. Note that this cell phone VM may be different than otherJava VM, even on the same model phone by the same manufacturer and/ormay be ultimately unique to the user.

The preparation may comprise applying one or more computer softwarepreparation transformations 16 to the computer software code 14.Further, the computer software preparation transformation 16 maycomprise encrypting the computer software code. It should be appreciatedthat the encryption may be any wide variety of available encryptiontechniques. The encryption, for example, may use a plurality of hiddenkeys. Moreover, the keys may be hidden within the execution environment26 and/or prepared software code 22. Similarly, the computer softwarepreparation transformation 16 may comprise adding additional codesand/or data to the computer software to verify the integrity of theexecution environment 26. Still yet, the computer software preparationtransformation 16 may comprise providing additional codes and/or data tothe computer software to verify the integrity of the prepared softwarecode. Still further yet, the computer software preparationtransformation 16 may comprise altering the computer software code suchthat proper execution (of the prepared software code, for example, butnot limited thereto) is difficult without undoing the alterations. Thealtering may include at least one of the following: altering constantoperands, program control flow, program data layout, data initializationinformation, instruction encoding, or file format, or any combinationthereof.

Prepare the Execution Environment

Referring to FIG. 15, there is provided a schematic block diagram of thecomputer method or system 10 that may comprise preparing the executionenvironment 26 such that it impedes the execution of computer softwarecode 14 in the execution environment except for a designated computersoftware code.

In contrast, a previous approach may have allowed the execution of acomputer software code within a generic (i.e., undesignated) executionenvironment. Additionally, a previous approach may have defined a widerange of static obscurity and/or static tamper resistancetransformations (i.e., prior to run time or execution time) that couldbe applied to an execution environment. Whereas, an embodiment of thepresent invention provides a method (or system or computer programproduct) for only allowing execution of a designated computer softwarecodes within an execution environment. That is, the executionenvironment is inextricably bound to the designated computer softwarecode. As an example, codes to verify integrity of the specifieddesignated computer software codes can be inserted into the executionenvironment, thereby increasing the obscurity of the executionenvironment and the binding the designated computer software codes tothe execution environment. For instance, an example of an applicationmay involve, but not limited there to, a cell phone manufacturer thatmay wish to have a Java VM that only executes the manufacturer's Javaprograms. The manufacture could insert integrity checks into the Java VMto verify that only the manufacturer's program can be run.

The preparation may comprise: applying one or more preparationtransformations 34 to the execution environment 26 computer softwarecode 14. The preparation transformation 16 may comprise encrypting someor all of the execution environment 26. The encryption may use aplurality of hidden keys. Further, the keys may be hidden within theexecution environment 26 and/or prepared software code 18. Moreover, thepreparation transformation 16 may comprise adding additional codesand/or data to the computer software to verify the integrity of thecomputer software code 14. Still yet, the preparation transformation 34may comprise providing additional codes and/or data to the computersoftware to verify the integrity of the prepared execution environment38.

Next, referring to FIG. 16, provided is a non-limiting example of aschematic block diagram of the computer method or system of increasingthe tamper-resistance and/or obscurity of computer software code 14 bypreparing both the compute software code 14 and the executionenvironment 26 as similarly discussed pertaining to FIGS. 2 and 16above.

Apply Execution Transformations During Execution of a Computer SoftwareCode

Referring to FIG. 1, there is provided a schematic block diagram of thecomputer method or system 10 for increasing the tamper-resistance and/orobscurity of computer software code 14.

In contrast, a previous approach may have allowed applied obscurityand/or tamper resistance transforms statically (i.e., prior to theexecution of the computer software code). Whereas, an embodiment of thepresent invention provides a method (or system or computer programproduct) for applying obscurity and/or tamper resistance transformsdynamically (i.e., during execution of the computer software codes),that which may possibly in a continuous manner or possibly periodic orrandom manner. Furthermore, an embodiment of the present inventionprovides a method (or system or computer program product) wherebypreviously transformed code and/or data may subsequently beretransformed, thereby further increasing obscurity and/or tamperresistance. For instance, an example of an application may involve, butnot limited there to, the data layout of access controlled software inproprietary television set top boxes that can be changed (i.e.transformed by the execution environment) every 300 hundred millisecondsof execution, for example. Set top boxes are subject to personsattempting to gain unauthorized access to set top services.

The method or system 10 may comprise applying execution transformations34 during execution of a computer software code 14 to improve tamperresistance and/or obscurity. The execution transformation may comprisethe execution environment changing the layout of computer software codedata. And whereby, the computer software code data may be data that isused for the execution environment or data to execute the computersoftware code 14 or data to execute prepared software code (as well bediscussed below). Further, the execution transformation may comprisesthe execution environment using conditions generated during execution,whereby the conditions are difficult to programmatically decipher toassist in the tamper-resistance and/or obscurity transforms. Still yet,the execution transformations may include relocating operationallocations to increase the difficulty of determining operation locationsfor making operation's locations difficult to determine. For instance,disassembly technique. See for example, 22, C. Linn, S. Debray, and J.Kececioglu.

Enhancing software tamper-resistance via stealthy address computations.Proceedings of the 19th Annual Computer Security Applications Conference(ACSAC 2003), 2003, of which is hereby incorporated by reference in itsentirety. Further yet, the execution transformations may includeinserting additional software code and/or data to make the executionflow and/or control flow difficult to determine. The executiontransformations may include rearranging, eliminating, or addingexecution flow for making execution flow and/or control flow difficultto determine. For instance, a control flow flatting technique. See forexample, 33, C. Wang, J. Hill, J. Knight, and J. Davidson. Softwaretamper resistance: Obstructing static analysis of programs. Universityof Virginia, Charlottesville, Va., 2000, of which is hereby incorporatedby reference in its entirety. Also, the execution transformations mayinclude creating software code that has operations that are difficult todetermine. Moreover, the execution transformations may include insertingoperations that cannot be feasibly executed, but appear as thoughexecution is possible. Additionally, the execution transformations mayinclude inserting incorrect codes that are intentionally similar toother correct software codes. Yet again, the execution transformationsmay include randomizing operation order. Further, the executiontransformations may insert operations to verify the integrity ofsoftware code and/or software data. Moreover, any one of the executiontransformations may comprise at least one of the following: control flowflattening, guards, disassembly resistance, self checksumming codes,dynamic disassembly resistance, control flow obfuscations, ABItransforms, API transforms, sequence transforms, calling conventiontransforms or data transform, or any combination thereof.

It should be appreciated that the execution environment may be a varietyof available types, including but not limited thereto the following:software dynamic translation (SDT), virtual machine (VM), Java VM,Strata VM, program simulators, program emulators, or virtualizationsystems, or any combinations thereof.

It should be appreciated that the e computer software code may be avariety of available types, including but not limited thereto thefollowing: binary, byte code, program source, program assembly, programscripts, machine language, or program intermediate formats, or anycombination thereof. Further, it should be appreciated that the programscripts may be a variety of available types, including but not limitedthereto the following: Perl, PHP, python, CGI, Java, Java Script, ASPscript, MySQL, Borne shell, bash, tcsh, or csh, or any combinationsthereof.

Further yet, it should be appreciated that the computer software code 14and/or computer software code data may comprises at least one of thefollowing: prepared computer software code and/or data, unpreparedcomputer software code and/or data, prepared execution environment codeand/or data, unprepared execution environment code and/or data, orpreviously transformed computer software code and/or data, or anycombinations thereof. It should be appreciated that the previouslytransformed computer software code and/or data may comprises at leastone of the following: cache, fragment cache, disk, disk drive, RAM,tape, magnetic tape drive, optical disk drive, or flash memory, or anycombination thereof. For instance, referring to FIG. 3, there isprovided a schematic block diagram of the computer method or system 10(or related method or computer program product) whereby executiontransformation occurs on the prepared software code 22. For instance,referring to FIG. 6, there is provided a schematic block diagram of thecomputer method or system 10 (or related method or computer programproduct) whereby the execution transformation 34 occurs not only on thecomputer software code 14, but also on the previously transformedcomputer software code and/or data of the execution environment softwarecode and/or data 28.

Similarly, referring to FIG. 5, there is provided a schematic blockdiagram of the computer method or system 10 (or related method orcomputer program product) whereby execution transformation 34 occurs notonly on the computer software code 14, but also on the preparedexecution environment software code and data 38.

Similarly, referring to FIG. 7, there is provided a schematic blockdiagram of the computer method or system 10 (or related method orcomputer program product) whereby execution transformation 34 occurs notonly on the prepared software code 22, but also on the previouslytransformed computer software code of the execution environment softwarecode and data 28.

Similarly, referring to FIG. 9, there is provided a schematic blockdiagram of the computer method or system 10 (or related method orcomputer program product) whereby execution transformation 34 occurs notonly on the computer software code 14, but also on the preparedexecution environment software code and data 38, as well as on thepreviously transformed computer software code or data of the executionenvironment software code and data 28.

Similar to FIG. 6, FIG. 10 provides a schematic block diagram of thecomputer method or system 10 (or related method or computer programproduct) whereby execution transformation 34 occurs not only on thecomputer software code 14, but also on the previously transformedcomputer software code and/or data of the execution environment softwarecode and data 28.

Referring to FIG. 11, there is provided a schematic block diagram of thecomputer method or system 10 (or related method or computer programproduct) comprising preparing 18 the computer software code 14 forexecution in an execution environment 26, but also applying executiontransformation 34 so that it occurs not only on the prepared softwarecode 22, but also on the previously transformed computer software codeand/or data of the execution environment software code and data 28.Further, the execution transformation may comprise undoing thepreparation transformations on the prepared software codes.

Similar to FIG. 9, referring to FIG. 13, there is provided a schematicblock diagram of the computer method or system 10 (or related method orcomputer program product) whereby execution transformation 34 occurs notonly on the computer software code 14, but also on the preparedexecution environment software code and data 38, as well as on thepreviously transformed computer software code and/or data of theexecution environment software code and data.

Referring to FIG. 4, there is provided a schematic block diagram of thecomputer method or system 10 (or related method or computer programproduct)comprising preparing 18 the computer software code 14 forexecution in an execution environment 26, but also applying executiontransformation 34 on both the prepared software code 22 and preparedexecution environment 38. Further, the execution transformation maycomprise undoing the preparation transformations on the preparedsoftware codes.

Referring to FIG. 8, there is provided a schematic block diagram of thecomputer method or system 10 (or related method or computer programproduct) comprising preparing 18 the computer software code 14 forexecution in an execution environment 26, but also applying executiontransformation 34 on both the prepared software code 22 and the preparedexecution environment 38 and on the previously transformed computersoftware code and/or data of the execution environment software code anddata 28. Further, the execution transformation may comprise undoing thepreparation transformations on the prepared software codes.

Referring to FIG. 12, there is provided a schematic block diagram of thecomputer method or system 10 (or related method or computer programproduct) comprising preparing 18 the computer software code 14 forexecution in an execution environment 26, but also applying executiontransformation 34 on the prepared software code 22 and preparedexecution environment 38 and on the previously transformed computersoftware code and/or data of the execution environment software code anddata 28.

Referring to FIG. 14, there is provided a schematic block diagram of thecomputer method or system 10 (or related method or computer programproduct) comprising preparing 18 the computer software code 14 forexecution in an execution environment 26, but also applying executiontransformation 34 on both the prepared software code 22 and on thepreviously transformed computer software code and/or data of theexecution environment software code and data 28, and repeat the processaccordingly. Further, the execution transformation may comprise undoingthe preparation transformations on the prepared software codes.

Some embodiments of the present invention may be implemented in softwarefor execution by a processor-based system 215, as shown in FIG. 36(A).For example, embodiments may be implemented in code and may be stored ona storage medium having stored thereon instructions which can be used toprogram a system, such as a wireless device to perform the instructions.The storage medium may include, but is not limited to, any type of diskincluding floppy disks, optical disks, compact disk read-only memories(CD-ROMs), compact disk rewritables (CD-RWs), and magneto-optical disks,semiconductor devices such as read-only memories (ROMs), random accessmemories (RAMs), such as a dynamic RAM (DRAM), erasable programmableread-only memories (EPROMs), flash memories, electrically erasableprogrammable read-only memories (EEPROMs), magnetic or optical cards, orany type of media suitable for storing electronic instructions,including programmable storage devices.

In many embodiments of the present invention, the processor-based system215 may include a processor 225 coupled to a display 230 and a systemmemory 232 through an interface 235. Illustrative interface 235 may be abridge circuit in one embodiment, or may include one or more buses inanother embodiment. The compiler 238, such as a commercial compiler, maybe loaded into the system memory 232 according to operations consistentwith certain embodiments of the present invention.

In the processor-based system 215, a primary bus 240 conforming to theperipheral component interface (PCI) standard, for example, may couple anetwork controller 245, a hard disk drive (HDD) 248 and a basicinput/output system (BIOS) to the processor 225 through the interface235. In this manner, the primary bus 240 may couple to the interface 235while providing an interface to peripheral devices. For some embodimentsof the present invention, the processor-based system 215 may beresponsible for distributing the compiler-modified code, for example.Other systems may be implemented in other embodiments of the presentinvention.

In different embodiments, however, wireless devices may be used. Awireless device 260 in accordance with one embodiment of the presentinvention, as shown in FIG. 36(B) may include a semiconductornonvolatile memory 300, a user interface 305, a wireless interface 310,and an antenna 320. In various embodiments, antenna 320 may be a dipole,helical, global system for mobile (GSM) communication antenna, or thelike. Components of the wireless device 260, which may be aprocessor-based device may further include a controller 275, aninterface 280, a read only memory (ROM) 285, and a random access memory(RAM) 290 coupled via an internal bus 295, according to one embodimentof the present invention. The interface 280 may enable communication viathe wireless interface 310 and the antenna 320 to a platform that maydistribute content, e.g., the compiler-modified code, for example.

Examples of the wireless device 260 may include mobile devices and/orcellular handsets that may be targeted for providing various subscriberservices by commercial vendors or service providers. To manipulate suchservices or simply to activate or reconfigure a device, content, e.g.,the compiler-modified code, for example, may be received via an over theair interface at the wireless device 260 in one embodiment.

Turning to FIG. 37, FIG. 37 is a functional block diagram for a computersystem 400 for implementation of an exemplary embodiment or portion ofan embodiment of present invention. For example, a method or system ofan embodiment of the present invention may be implemented usinghardware, software or a combination thereof and may be implemented inone or more computer systems or other processing systems, such aspersonal digit assistants (PDAs) equipped with adequate memory andprocessing capabilities. In an example embodiment, the invention wasimplemented in software running on a general purpose computer 400 asillustrated in FIG. 37. The computer system 400 may includes one or moreprocessors, such as processor 404. The Processor 404 is connected to acommunication infrastructure 406 (e.g., a communications bus, cross-overbar, or network). The computer system 400 may include a displayinterface 402 that forwards graphics, text, and/or other data from thecommunication infrastructure 406 (or from a frame buffer not shown) fordisplay on the display unit 430. Display unit 430 may be digital and/oranalog.

The computer system 400 may also include a main memory 408, preferablyrandom access memory (RAM), and may also include a secondary memory 410.The secondary memory 410 may include, for example, a hard disk drive 412and/or a removable storage drive 414, representing a floppy disk drive,a magnetic tape drive, an optical disk drive, a flash memory, etc. Theremovable storage drive 414 reads from and/or writes to a removablestorage unit 418 in a well known manner. Removable storage unit 418,represents a floppy disk, magnetic tape, optical disk, etc. which isread by and written to by removable storage drive 414. As will beappreciated, the removable storage unit 418 includes a computer usablestorage medium having stored therein computer software and/or data.

In alternative embodiments, secondary memory 410 may include other meansfor allowing computer programs or other instructions to be loaded intocomputer system 400. Such means may include, for example, a removablestorage unit 422 and an interface 420. Examples of such removablestorage units/interfaces include a program cartridge and cartridgeinterface (such as that found in video game devices), a removable memorychip (such as a ROM, PROM, EPROM or EEPROM) and associated socket, andother removable storage units 422 and interfaces 420 which allowsoftware and data to be transferred from the removable storage unit 422to computer system 400.

The computer system 400 may also include a communications interface 424.Communications interface 424 allows software and data to be transferredbetween computer system 400 and external devices. Examples ofcommunications interface 424 may include a modem, a network interface(such as an Ethernet card), a communications port (e.g., serial orparallel, etc.), a PCMCIA slot and card, a modem, etc. Software and datatransferred via communications interface 424 are in the form of signals428 which may be electronic, electromagnetic, optical or other signalscapable of being received by communications interface 424. Signals 428are provided to communications interface 424 via a communications path(i.e., channel) 426. Channel 426 (or any other communication means orchannel disclosed herein) carries signals 428 and may be implementedusing wire or cable, fiber optics, blue tooth, a phone line, a cellularphone link, an RF link, an infrared link, wireless link or connectionand other communications channels.

In this document, the terms “computer program medium” and “computerusable medium” are used to generally refer to media or medium such asvarious software, firmware, disks, drives, removable storage drive 414,a hard disk installed in hard disk drive 412, and signals 428. Thesecomputer program products (“computer program medium” and “computerusable medium”) are means for providing software to computer system 400.The computer program product may comprise a computer useable mediumhaving computer program logic thereon. The invention includes suchcomputer program products. The “computer program product” and “computeruseable medium” may be any computer readable medium having computerlogic thereon.

Computer programs (also called computer control logic or computerprogram logic) are may be stored in main memory 408 and/or secondarymemory 410. Computer programs may also be received via communicationsinterface 424. Such computer programs, when executed, enable computersystem 400 to perform the features of the present invention as discussedherein. In particular, the computer programs, when executed, enableprocessor 404 to perform the functions of the present invention.Accordingly, such computer programs represent controllers of computersystem 400.

In an embodiment where the invention is implemented using software, thesoftware may be stored in a computer program product and loaded intocomputer system 400 using removable storage drive 414, hard drive 412 orcommunications interface 424. The control logic (software or computerprogram logic), when executed by the processor 404, causes the processor404 to perform the functions of the invention as described herein.

In another embodiment, the invention is implemented primarily inhardware using, for example, hardware components such as applicationspecific integrated circuits (ASICs). Implementation of the hardwarestate machine to perform the functions described herein will be apparentto persons skilled in the relevant art(s).

In yet another embodiment, the invention is implemented using acombination of both hardware and software.

In an example software embodiment of the invention, the methodsdescribed above may be implemented in SPSS control language or C++programming language, but could be implemented in other variousprograms, computer simulation and computer-aided design, computersimulation environment, MATLAB, or any other software platform orprogram, windows interface or operating system (or other operatingsystem) or other programs known or available to those skilled in theart.

Further, it should be appreciated that software or code and datatransferred via communications interface or other give modules may be inthe form of signals which can be electronic, electromagnetic, optical orother signals capable of being received by communications interface orother modules. The invention is described in these terms for conveniencepurposes only. Further, it should be clear to one skilled in the artthat the invention may be applied to a variety of computer or controlsystems. Such systems would include all manner of appliances havingcomputer or processor control including telephones, mobile telephones,cellular telephones, televisions, multimedia, games, video games,television set top units, lap top computers, personal digital assistants(PDAs), satellites, mobile computers, media players, satellite set top,cable set top, digital rights management (DRM), digital rights adapters(DTAs), music players, and automobiles or other land, air, or watervehicles.

Further, it should be appreciated that any of the modules, apparatuses,machines, sub-machines, components, sub-components, systems,sub-systems, software, hardware, firmware, means, drivers, engines,integrated circuits (ICs), and/or application specific integratedcircuits (ASICs) disclosed herein may be interchangeable with oneanother to practice the invention.

It should be appreciated that any of the modules, apparatuses, machines,sub-machines, components, sub-components, systems, sub-systems,software, hardware, firmware, means, drivers, engines, integratedcircuits (ICs), and/or application specific integrated circuits (ASICs)disclosed herein may be integrally or separately formed with oneanother.

It should be appreciated that any of the modules, apparatuses, machines,sub-machines, components, sub-components, systems, sub-systems,software, hardware, firmware, means, drivers, engines, integratedcircuits (ICs), and/or application specific integrated circuits (ASICs)disclosed herein may be communicated locally and, or remotely with anyuser, operator, soldier, clinician, patient, astronaut, pilot, driver,technician, navigator, officer, employee, or machine, system, computer,processor.

It should be appreciated that any of the modules, apparatuses, machines,sub-machines, components, sub-components, systems, sub-systems,software, hardware, firmware, means, drivers, engines, integratedcircuits (ICs), and/or application specific integrated circuits (ASICs)disclosed herein may be may be in communication via wireless and/orhardwire or other desirable and available communication means, systemsand hardware.

It should be appreciated that any means-plus function arrangementtechnique may be replaced with or equivalent to any module, apparatuses,machine, sub-machine, component, sub-component, system, sub-system,software, hardware, firmware, driver, engine, integrated circuit (ICs),and/or application specific integrated circuit (ASIC) disclosed herein

Further, it should be clear to one skilled in the art that the inventionmay be applied to a variety of computer or control systems and theirintended applications such as business policy, business assets, variousapplications such as data bases in enterprise data centers to consumerdevices.

An aspect of various embodiments of the present invention may provide anumber of novel and nonobvious features, elements and characteristics,such as but not limited thereto, the following:

A strong method for binding a software dynamic translation system (orany virtual machine) to an application, such that the application cannotbe run without the SDT;

Dynamically generating and inserting opaque predicates into running codevia a virtual machine;

Dynamically applying program obfuscation within a virtual machine;

A new approach to self-checksumming that is more difficult to circumventthan previously proposed techniques;

The various embodiments of the invention may be used to vaccinate anexecutable from attack via a virus. Since the executable is resistanteven from manual modification, viruses cannot automatically insertcopies of themselves;

Use of a strong encryption algorithm (such as an encryption algorithmlike PKI, symmetric and asymmetric) to guarantee that application textcannot be modified to remove self checksumming guard code;

Code cache flushing to reduce dynamic information leakage and present anattacker (or attacking program) constantly morphing code. This morphingcan prevent significant dynamic information leakage; and/or

Using dynamic obfuscations specifically designed to keep an intelligentadversary from manually or programmatically merging code fragments fromdifferent executions of the program.

Examples and Experimental Results

Practice of the invention will be still more fully understood from thefollowing examples and experimental results, which are presented hereinfor illustration only and should not be construed as limiting theinvention in any way.

Example Nos. 1-16

See FIGS. 17-32, which pertain to specific exemplary (and non-limiting)embodiments as they may pertain to the approach illustrating the presentinvention computer method, system or computer program productembodiments of FIG. 1-16, respectively.

Example No. 17

An aspect of the embodiment of the present invention provides a way toprotect an application using a virtual machine and a variety ofmechanisms to make sure that the virtual machine cannot be modified.First, the application's code segment is encrypted. The encrypted texthas code to checksum itself and the virtual machine. As the applicationrequests new fragments to execute, the virtual machine decrypts portionsof the application's code segment, applies anti-tampering (includingdynamic self-checksumming) and obfuscation (including dynamic resistanceto disassembly, dynamic control flow graph hiding, dynamic instructionisomorphisms, dynamic dead code, and dynamic code scheduling) techniquesto prevent revealing the application's instructions during execution.Combined with frequent flushing of the virtual machine's fragment cache,this invention provides significantly stronger protection thanstatically-applied anti-tampering and obfuscation alone.

Most anti-tampering and obfuscation schemes require the application tobe in an executable format. Whereas an aspect of the present inventionleverages the security of a strongly encrypted binary by relying onStrata to perform just-in-time decryption.

To provide strong assurance against any static attacks, the inventionuses a proven strong encryption algorithm, such as AES [See 29, D. Lie,C. Thekkath, M. Mitchell, P. Lincoln, D. Boneh, J. Mitchell, and M.Horowitz. Architectural support for copy and tamper resistant software.ACM SIGPLAN Notices, 35(11):168-177, 2000, of which is herebyincorporated by reference in its entirety]. The entire text segment ofthe application is encrypted and remains that way for the entireexecution of the program. When a new PC from the executable is requestedto be translated, the block(s) containing the application code arecopied to a buffer, and the buffer is decrypted, the requestedinstruction(s) are translated into the fragment cache, and the buffer iszeroed to prevent decrypted code from being present longer thannecessary. FIG. 33 shows an illustration. In the figure, the “hatched”portion on the right represents the application which has beenencrypted—prepared software code 22. Strata 26, of course, needs to runon the processor to decrypt the application, and cannot be encrypted.Likewise, the fragment cache 38 cannot be encrypted.

Strata itself can remain unencrypted as understanding Strata provideslittle understanding of the encrypted application. That is not to saythat Strata does not need protection from tampering, but theunderstanding of Strata need not be kept secret. The fragment cache,however, can neither be encrypted (as it must contain instructions thatrun on standard hardware) nor can it be easily left unprotected as itcontains the instructions needed to run the application.

Like the fragment cache, the decryption key must be protected. If thiskey is available (dynamically or statically), then the adversary canscan memory to discover it, and easily decrypt the entire text segmentand find out the contents of the original

Strata must have the ability to decrypt the application text in order torun the program. However, in most circumstances it is not necessary tohave a 128-bit encryption key unprotected in memory. The approach we useto protect the key is the same as outlined by Chow [See 5, S. Chow, P.Eisen, H. Johnson, and P. C. van Oorschot. White-box cryptography and anAES implementation. Proceedings of the Ninth Workshop on Selected Areasin Cryptography (SAC 2002), 2002. and See 20, H. E. Link and W. D.Neumann. Clarifying obfuscation: Improving the security of white-boxencoding. Sandia National Laboratories, Albuquerque, N.M., downloadedfrom eprint.iacr.org/2004/025.pdf, 2004, both of which are herebyincorporated by reference herein in their entirety.]. Basically, theconstant key is propagated throughout the decryption routine, and randombijections are used at each step of the AES computation to make the keysignificantly harder to extract. Unfortunately, the key is notimpossible to extract, but it does take significant computation time[See 3, O. Billet, H. Gilbert, and C. Ech-Chatbi. Cryptanalysis of awhite box AES implementation, 2004, of which is hereby incorporated byreference herein in its entirety]. An embodiment of the invention maycounter this weakness by having different portions of an applicationencrypted by different keys (represented by different patterning in FIG.33). Some portions are encrypted repeatedly, to make it harder for theattacker to recover AES keys and decrypt the binary.

By having the key(s) protected in this manner, it is difficult for anattacker to extract the key(s) needed to decrypt the program.Furthermore, even if they can observe the decryption buffer, it is verydifficult for an attacker to make small changes to the applications textsegment. For example, if a decryption block contains a guard, and otherinstructions necessary for the program to run, the attack cannot convertthe guard code to no-operation instructions without knowing the key usedto encrypt that block. An embodiment of the invention can provably avoidthe ability for an attacker to encrypt code to make small changes byusing an encryption algorithm (e.g., symmetric and asymmetric).

For the encryption to be useful, the embodiment of the invention shallensure that even if an adversary is able to decrypt the binary, whichthe binary may only run under Strata's control. To achieve this goal,the embodiment of the invention provides two mechanisms. The first isthat there are self-checksumming guards within the encrypted executable.These guards not only checksum the application, but also checksumStrata's code. Secondly, the decrypted code need not execute properly onany standard machine. A variety of obfuscations are possible that wouldbreak normal code, but under Strata's control can be “undone” attranslation times. For example, most call instructions specify a targetaddress. The binary form could have an address f (addr) specified, andwhen Strata translates the instruction it applies f¹ (addr) to theaddress. There are an infinite number of one-to-one onto functions thatcould be applied to varying types of instructions: Opcodes could beshuffled, addressing mode bits could be shuffled, instruction lengthscould be arbitrarily increased, the “next instruction” calculation couldbe changed, or a variety of difficult to undo transformations applied.Together, these techniques make it very difficult for an attacker tosuccessfully run the program without Strata performing the translation.

Although the static protection model outlined above is quite strong, itmay still be possible for an adversary to monitor the dynamic executionof the program. For example, the adversary may be able to snapshoot thecontents of the fragment cache at any point. If the fragment cache is anexact (or close) representation of the entire program, the adversary caneasily snapshot the program and perform standard attacks on theunprotected code.

To combat this problem, an embodiment of the invention applies a varietyof dynamic protections.

A key to software dynamic translation is the fragment cache and goodlocality of the code within it. Unfortunately, for anti-tampering andobfuscation, this locality is perhaps also SDT's greatest weakness. Asthe program executes, the program's encrypted code gets decrypted (asneeded) and materializes in the fragment cache. If an adversary cancapture the contents of the code cache just before program termination,they can get a snapshot of all the instructions needed to run theprogram. Luckily a solution is easy: flush the fragment cacheperiodically. Taken to the limit, the fragment cache could be flushedafter each instruction is executed. Per instruction flushing would leakthe minimum amount of information about the application as it executes;an adversary would never learn more than one application instructionfrom any inspection of memory. Unfortunately flushing the code cacheafter every instruction causes the system to spend most of its timeflushing and regenerating fragments into the code cache, and very littletime executing application instructions.

Instead, the code cache needs to be flushed at an interval in whichlittle information is leaked about the application instructions, yethigh efficiency is maintained. Flushing the code cache periodicallyhides information from an adversary, but if much of the applicationmaterializes in the code cache very quickly (say, in half the flushinginterval or less), the amount of hiding may be minimal. To determine howmuch information hiding is occurring, consider FIG. 34. The figure showsthe percentage of gcc's application text that is materialized into thecode cache over the course of a single execution of the program. Fromthe figure, we can conclude that even basic software dynamic translationkeeps less than 45% of the application text from being visible. Flushingevery 10 seconds does provide some benefit, much of the application isneeded only during startup or shutdown, and is discarded shortly after10 seconds into the execution of the program. Flushing every second doessignificantly better at keeping the application's text hidden. For amajority of the program's execution, less than 10% of the application'stext resides in the fragment cache! Flushing every 0.1 seconds does evenbetter; most of the time less than 3% of gcc's text is visible in thecode cache.

We have performed preliminary measurements on the cost of flushing thefragment cache, shown in FIG. 35. The graph shows the performance of ourSDT system, Strata, for the C benchmarks in the SPEC2000 benchmarksuite. The first bar shows the overhead with no fragment cache flushing.Overhead averages about 18% slower than native execution. The next threebars show flushing the cache every 10 seconds, 1 second, and 0.1seconds. Overhead averages 19%, 23%, and 47% respectively. Obviously,blindly flushing every 10th of a second provides significant overhead,but results are encouraging that flushing every 1 second provides lessthan 5% additional overhead. Furthermore, we believe that flushingintelligently may have additional benefits. For example, by selectivelyflushing only fragments that have not been used recently we can hidedynamic information from an adversary without impacting performance.Also, we expect (selectively) flushing the code cache after a programphase is complete can hide information with little performance loss.

In our prototype implementation, the operating system must send a signalto the application in order for Strata to know that the code cacheshould be flushed. A malicious operating system could bypass theflushing mechanism by not delivering the signal. Other techniques, suchas having fragments “expire” after being executed a predetermined numberof times can provide a stronger guarantee about ensuring the code cacheis flushed after a certain number of fragments are executed.

Flushing the code cache can keep any one snapshot from revealing muchabout the application, but an adversary may take multiple snapshots ofmemory and attempt to piece together the contents of the entireapplication. To prevent an adversary from being able to easily piecetogether the code necessary to run the application, Strata can applyobfuscating transformations at fragment translation time. To serve asthe base of a variety of dynamic transformations, we introduce theconcept of a dynamic opaque predicate.

An opaque predicate is a predicate that is known at compile-time, but isvery difficult (NP-Hard) to determine statically once compilation iscomplete. Although these predicates provide strong resistance to staticattacks, they provide little strength against dynamic attacks becauseonce an opaque predicate is calculated dynamically, an adversary knowsall the information about the predicate. By creating an opaque predicatethat is known at fragment creation time, or a dynamic opaque predicate,it becomes significantly more difficult for an adversary to know whichof the conditional branches are highly biased simply to provideobfuscating transformations, and which is part of the program.

Upon the concept of a dynamic opaque predicate, the dynamic translationsystem can apply dynamic versions of many static obfuscation techniques.Some of the most powerful are disassembly resistance and control flowgraph obfuscation.

One way to obfuscate the code cache is to make it difficult to determinewhich portions of the code cache are instructions and which portions arenot. By inserting a dynamically generated opaque predicate, thetranslator can use the never taken direction to 1) insert instructionsthat branch to a location in the code cache that is not actually a validinstruction, or 2) insert partial “instructions.” Inserting thisinformation will make an automatic disassembler become out ofsynchronization with the actual instruction stream. By branching to anon-instruction, a recursive-descent disassembler soon has troubledetermining which instructions are actual branch targets and which onesare not. By inserting partial “instructions”, a linear scan disassemblerquickly becomes out of sync.

If the code that is designed to confuse disassemblers has predictableplacement or makes up only a small portion of the fragment cache, thesecurity measures can easily be thwarted. On the other hand, ifcalculating the predicate and performing the branch is done toofrequently, performance can suffer. One technique that may be useful isto place more security in less frequently executed fragments.

Dynamic opaque predicates can provide an efficient mechanism to make itmore difficult to automatically disassemble the fragment cache. However,it is also important to make it difficult to extract the program'scontrol flow graph. If each rematerialization of the fragment cache hasthe same control flow graph, it may be possible for an adversary to usethe control flow information to stitch together many fragment cachesnapshots to gain complete knowledge of the application. To avoid anycontrol flow graph information leakage, a technique similar todisassembly resistance is used. The invention uses a dynamicallygenerated opaque predicate to provide a mechanism in which each fragmentappears to jump to many other fragments, but only certain paths canactually be taken. These paths will contain conditional jumps,unconditional jumps, calls (including argument passing code), hard toanalyze indirect jumps, returns (including stack tear-down code), andcombinations of these techniques.

Such a technique provides a good way to provide false information aboutthe control flow graph, but does not allow the real control flow graphto be obscured. It is possible to convert some direct jumps and callsinto indirect versions. By having the target of the indirect branchcalculated using opaque predicates to obfuscate the actual target, wecan force the adversary to observe the execution of some branches inorder to accurately determine the control flow graph for even a singlefragment cache snapshot.

Compiler writers have long known that there are many efficientinstruction sequences to achieve a goal. For example, on the IA-32, thefollowing instructions are equivalent: a) add % eax, #1 b) sub % eax,#−1 and c) lea % eax, % eax+1 all add the constant 1 to the registereax. There are even more options if the constant 1 or −1 is stored inmemory and a complex addressing mode is used instead of an immediateaddressing mode. A dynamic translation system can use an instructionset's variety to generate each fragment using different instructionopcodes and addressing modes. Since an application's instructions willbe translated differently each time, it becomes more difficult for anadversary to piece together multiple fragment cache snapshots to form acomplete picture of the application's code.

Unfortunately, an adversary may try to produce a canonical form for eachinstruction. Our example add instructions could all be converted toeax=eax+1, for example. To combat this approach, the translator canperform a many-to-many transformation on several data-dependentinstructions. By moving operations between instructions it becomessignificantly more difficult to form any canonical form that isequivalent to corresponding code from another fragment cache snapshot.To solve this problem, an adversary must form data dependence graphs foreach fragment in a snapshot of the code cache, and try to match graphsfrom each snapshot. This is a difficult, NP-Hard problem for even twosnapshots. With frequent flushing, there may be hundreds or thousands ofcode cache snapshots that need to be matched. Thus, undoing theisomorphism transformations would be extremely difficult, if notintractable.

Although many-to-many instruction isomorphisms can provide a significantresistance to revealing the application's instruction sequence, they mayalso be expensive to calculate or more expensive during execution.Careful consideration is needed when deciding how and when to utilizeinstruction isomorphisms as well as how to efficiently calculate them.One promising avenue of research is to pre-calculate the most neededmany-to-many transformations at compile time and store them in theexecutable in encrypted form. The translator can carefully look up theseisomorphisms and apply them with minimal overhead.

Compilers spend significant effort trying to eliminate dead (neverexecuted) or useless code. An SDT system can carefully insert dead oruseless code for the purposes of obfuscation. For example, thetranslator can insert instructions from other parts of the applicationto make it hard to line up fragments from multiple fragment cachesnapshots. Dead code can be inserted in a critical algorithm to make thedataflow or control flow harder to understand. Furthermore, non-workingversions of a critical algorithm can be intermixed with other code thatis less important in order to distract an adversary into analyzing thewrong portions of code or being unable to determine which version of thecode is the correct version.

Another way to make fragment cache snapshots appear different and forcean adversary to perform NP-hard data dependence graph matching is todynamically reschedule the code. The dynamic translation system canperform traditional instruction scheduling on each fragment as it iscreated, but use different evaluation criteria (including apseudo-random number generator) for making scheduling decisions duringeach time frame. Perhaps of more importance is that any dynamicallygenerated code for obfuscation or anti-tampering will be dispersedwithin the application's instructions.

Dynamically generating and using opaque predicates and otherobfuscations can make it more difficult for an adversary to understandhow many snapshots of the fragment cache may work together, but does notdirectly protect the fragment cache from changes being applied. Toprovide more direct protection for the fragment cache, the inventionalters Strata to insert self-checksumming code into the fragment cache.This code performs checksums on the fragment cache directly. Like staticself-checksums, the code in the fragment cache calculates and verifiesthat portions of the code (the original application's code, Strata'scode, and most importantly code within the fragment cache) areunmodified. Also like static self checksumming, when a guard fails, itmust alter the program's execution in such a way that the program is nolonger usable. However, unlike static self checksumming, since guardsare generated dynamically and randomly during dynamic translation,revealing the guard's location once a failure occurs is of littleconcern: the guard will be different on future executions of theprogram. An important aspect may be, however, that the guard cannot berevealed until it has failed, thus it must not simply execute aninstruction sequence to abort the program. Instead, the guard will use adynamic opaque predicate to help calculate an indirect branch target,such that it is not clear that an abort is going to happen until theguard fails.

Considering the importance of tamper resistance, much work has been donein this area. Perhaps the most widely known is self-checksumming. Horne,et al. describe how guards or testers are inserted throughout theapplication [See 12, B. Horne, L. R. Matheson, C. Sheehan, and R. E.Tarjan. Dynamic self-checking techniques for improved tamper resistance.Digital Rights Management Workshop, pages 141-159, 2001, of which ishereby incorporated by reference in its entirety.]. Each guard checksumsa portion of the application's code (including other guards) and failssubtly if a modification is detected. Wurster, et al. quickly noted asimple work around to the guards: separate program and data memory [See34, G. Wurster, P C van Oorschot, and A. Somayaji. A generic attack onchecksumming-based software tamper resistance. Proceedings of the 2005IEEE Symposium on Security and Privacy, pages 127-138, 2005, and See 32,P. C. van Oorschot, A. Somayaji, and G. Wurster. Hardware-assistedcircumvention of self-hashing software tamper resistance. IEEETransactions on Dependable and Secure Computing, 2(2):82-92, 2005, bothof which are hereby incorporated by reference in their entirety.].Giffin noted a way to prevent this attack with the addition ofself-modifying guard code [See 10, J. T. Giffin, M. Christodorescu, andL. Kruger. Strengthening software self-checksumming via self-modifyingcode. Proceedings of the 21st Annual Computer Security ApplicationsConference, pages 23-32, 2005, of which is hereby incorporated byreference in its entirety]. Neither technique, however, providesresistance to dynamic techniques that identify guards and remove them.Indeed, the self-modifying code may make the guards harder to disguiseas most programs do not use any form of self modification.

Many other tamper-resistance techniques rely on special hardware [See19, D. Lie, C. Thekkath, M. Mitchell, P. Lincoln, D. Boneh, J. Mitchell,and M. Horowitz. Architectural support for copy and tamper resistantsoftware. ACM SIGPLAN Notices, 35(11):168-177, 2000, See 24, T. Maudeand D. Maude. Hardware protection against software piracy.Communications of the ACM, 27(9):950-959, 1984, See 1, D. J. Albert andS. P. Morse. Combatting software piracy by encryption and keymanagement. Computer, 17(4):68-73, 1984, See 27, A. Seshadri, M. Luk, E.Shi, A. Perrig, L. van Doom, and P. Khosla. Pioneer: verifying codeintegrity and enforcing untampered code execution on legacy systems.Proceedings of the 20th ACM symposium on Operating Systems Principles,pages 1-16, 2005, and See 28, G. E. Suh, D. Clarke, B. Gassend, M. vanDijk, and S. Devadas. AEGIS: architecture for tamper-evident andtamper-resistant processing. Proceedings of the 17th AnnualInternational Conference on Supercomputing, pages 160-171, 2003, all ofwhich are hereby incorporated by reference in their entirety]. Forexample, Suh, et al. propose hardware to enable tamper-evident software[See 28, G. E. Suh, D. Clarke, B. Gassend, M. van Dijk, and S. Devadas.AEGIS: architecture for tamper-evident and tamper-resistant processing.Proceedings of the 17th Annual International Conference onSupercomputing, pages 160-171, 2003, of which is hereby incorporated byreference in its entirety]. The Pioneer system proposed by Seshadri, etal. requires that the system have secure and reliable networkconnections and all details of the system are known at software creationtime [See 27, A. Seshadri, M. Luk, E. Shi, A. Perrig, L. van Doorn, andP. Khosla. Pioneer: verifying code integrity and enforcing untamperedcode execution on legacy systems. Proceedings of the 20th ACM symposiumon Operating Systems Principles, pages 1-16, 2005, of which is herebyincorporated by reference in its entirety]. Although these systems mayprovide stronger security guarantees, the threat model requires moreknowledge than our threat model requires. Namely, the threat modelrequires some form of hardware. Unfortunately, it is non-trivial toadapt such systems to the extremely challenging threat model we believeis necessary for real-world protection.

Encrypting the binary to provide resistance to tampering, obfuscation,and anti-piracy was proposed long ago but was believed to requirehardware for efficiency purposes [See 19, D. Lie, C. Thekkath, M.Mitchell, P. Lincoln, D. Boneh, J. Mitchell, and M. Horowitz.Architectural support for copy and tamper resistant software. ACMSIGPLAN Notices, 35(11):168-177, 2000, and See 24, T. Maude and D.Maude. Hardware protection against software piracy. Communications ofthe ACM, 27(9):950-959, 1984, both of which are hereby incorporated byreference in their entirety]. The use of ultra-efficient softwaredynamic translation has enabled us to use encryption to prevent codeinjection attacks with little overhead [See 13, Wei Hu, Jason D. Hiser,Daniel Williams, Adrian Filipi, Jack W. Davidson, David Evans, John C.Knight, Anh Nguyen-Tuong, and Jonathan Rowanhill. Secure and practicaldefense against code-injection attacks using software dynamictranslation. In Proceedings of the 2nd International Conference onVirtual Execution Environments, pages 2-12. ACM Press New York, N.Y.,USA, 2006, of which is hereby incorporated by reference in itsentirety]. Our proposed techniques use SDT to help provide a system thatuses encryption without sacrificing efficiency.

The largest portion of tamper-resistance research involves making theprogram difficult to understand. It is widely believed that some levelof understanding of the program is necessary in order to make meaningfulmodifications. For example, if self-checksumming is used, it isnecessary to understand which instructions are needed for the selfchecksumming and which are needed for execution of the program beforechanges can be made. Techniques that make it difficult to understand aprogram may actually be best described as obfuscations. Previousobfuscation work can be classified into two types: static and dynamic.

Static obfuscation techniques aim to make the program difficult tostatically analyze [See 8, C. Collberg, C. Thomborson, and D. Low.Manufacturing cheap, resilient, and stealthy opaque constructs. InProceedings of the 25th ACM SIGPLAN-SIGACT Symposium on Principles ofProgramming Languages, pages 184-196. ACM Press New York, N.Y., USA,1998, See 17, C. Kruegel, W. Robertson, F. Valeur, and G. Vigna. Staticdisassembly of obfuscated binaries. In Proceedings of the 13th USENIXSecurity Symposium, Berkeley, Calif., USA, 2004. USENIX Association, See22, C. Linn, S. Debray, and J. Kececioglu. Enhancing softwaretamper-resistance via stealthy address computations. Proceedings of the19th Annual Computer Security Applications Conference (ACSAC 2003),2003, and See 33, C. Wang, J. Hill, J. Knight, and J. Davidson. Softwaretamper resistance: Obstructing static analysis of programs. Universityof Virginia, Charlottesville, Va., 2000, all of which are herebyincorporated by reference in their entirety]. This can be done by usingproblems that are known to be NP-Hard to solve statically. One exampleis using alias analysis to create opaque constructs [See 8, C. Collberg,C. Thomborson, and D. Low. Manufacturing cheap, resilient, and stealthyopaque constructs. In Proceedings of the 25th ACM SIGPLAN-SIGACTSymposium on Principles of Programming Languages, pages 184-196. ACMPress New York, N.Y., USA, 1998, of which is hereby incorporated byreference in its entirety] to prevent easy disassembly of the program[See 21, C. Linn and S. Debray. Obfuscation of executable code toimprove resistance to static disassembly. Proceedings of the 10th ACMconference on Computer and Communications Security, pages 290-299, 2003,of which is hereby incorporated by reference in its entirety.]. Anotherexample is using aliases to obscure the program's control flow graph[See 33, C. Wang, J. Hill, J. Knight, and J. Davidson. Software tamperresistance: Obstructing static analysis of programs. University ofVirginia, Charlottesville, Va., 2000, of which is hereby incorporated byreference in its entirety.]. Although these techniques provide verypowerful guarantees about the information that can be gained from staticanalysis, they provide little strength against attacks that observe theexecution of the program. For example, tracing the instruction sequencewith a simulator provides exact information for disassembling theprogram. An aim was to provide resistance against all forms of attacks,including attacks that combine static and dynamic information.

Another class of obfuscation techniques are dynamic obfuscations whichmake static attacks difficult by using self-modifying code to obscurewhere the program's instructions are located [See 23, M. Madou, B.Anckaert, P. Moseley, S. Debray, B. De Sutter, and K. De Bosschere.Software protection through dynamic code mutation. Proceedings of the6th International Workshop on Information Security Applications (WISA,pages 194-206, 2005, See 2, D. Aucsmith. Tamper resistant software: animplementation. In Proceedings of the First International Workshop onInformation Hiding, pages 317-333. Springer-Verlag London, UK, 1996, andSee 15, Y. Kanzaki, A. Monden, M. Nakamura, and K. Matsumoto. Exploitingself-modification mechanism for program protection. Proceedings of the27th Annual International Computer Software and Applications Conference,pages 170-179, 2003, all of which are hereby incorporated by referencein their entirety.]. One example uses edit scripts [See 23, M. Madou, B.Anckaert, P. Moseley, S. Debray, B. De Sutter, and K. De Bosschere.Software protection through dynamic code mutation. Proceedings of the6th International Workshop on Information Security Applications (WISA,pages 194-206, 2005, of which is hereby incorporated by reference in itsentirety.]. The edit scripts are run by an editing engine that patchesfunctions just before execution and hides the function after execution.For efficiency, the replacement is done “in place.” Again, an adversarythat is observing the dynamic instruction trace may be able to removethe editing scripts and place the correct functions in the proper place.Our work strives to make this impossible by continually performingobfuscations and applying tamper-resistant guards. Perhaps the strongestdynamic technique was proposed by Aucsmith, et al. [See 2, D. Aucsmith.Tamper resistant software: an implementation. In Proceedings of theFirst International Workshop on Information Hiding, pages 317-333.Springer-Verlag London, UK, 1996, of which is hereby incorporated byreference in its entirety.]. This technique involves the creation andexecution of “integrity verification kernels” that each use and generatecryptographic keys. Multiple threads are executed in a nondeterministicmanner to make it difficult for an adversary to trace the execution ofthe program. Unfortunately, it is unclear how to implement thistechnique, especially if program efficiency is a concern.

An interesting, but related subject is software aging or evolution [See6, F. B. Cohen. Operating system protection through program evolution.Computers and Security, 12(6):565-584, 1993, and See 14, M. Jakobssonand M. Reiter. Discouraging software piracy using software aging.Digital Rights Management Workshop, pages 1-12, 2001, both of which arehereby incorporated by reference in their entirety.]. Software agingtechniques attempt to mitigate the cost of piracy by continuallyupdating software with new cryptographic keys. Pirated software fails toget the updates, and soon becomes significantly less useful, or incurslarge performance overhead. Unfortunately, these techniques are onlyapplicable to document-centric applications. Furthermore, by themselves,they provide little resistance to tampering with a system.

A description of anti-tampering, obfuscation, and de-obfuscationtechnology is provided in cited references [See 25, G. Naumovich and N.Memon. Preventing piracy, reverse engineering, and tampering. Computer,36(7):64-71, 2003, See 9, C S Collberg and C. Thomborson. Watermarking,tamper-proofing, and obfuscation-tools for software protection. IEEETransactions on Software Engineering, 28(8):735-746, 2002, See 7, C.Collberg, C. Thomborson, and D. Low. A taxonomy of obfuscatingtransformations. University of Auckland Technical Report, 170, 1997, See23, M. Madou, B. Anckaert, P. Moseley, S. Debray, B. De Sutter, and K.De Bosschere. Software protection through dynamic code mutation.Proceedings of the 6th International Workshop on Information SecurityApplications (WISA, pages 194-206, 2005, and See 31, S K Udupa, S KDebray, and Matias Madou. Deobfuscation: Reverse engineering obfuscatedcode. Reverse Engineering, 12th Working Conference on, pages 45-54,2005, all of which are hereby incorporated by reference in theirentirety.].

The following patents, applications and publications as listed below arehereby incorporated by reference in their entirety herein.

The devices, systems, compositions, computer program products,processors, means and methods of various embodiments of the inventiondisclosed herein may utilize aspects disclosed in the followingreferences, applications, publications and patents and which are herebyincorporated by reference herein in their entirety:

-   -   1. U.S. Pat. No. 7,366,914, Apr. 29, 2008, “Source Code        Transformation Based on Program Operators”, Graunke, Gary L.    -   2. U.S. Patent Application Publication 2003/0018906 A1, Jan. 23,        2003, “Method and System for Protecting Software Applications        Against Static and Dynamic Software Piracy Techniques”, Smith,        Michael D.    -   3. U.S. Patent Application Publication 2005/0050355 A1, Mar. 3,        2005, “Securing Distributable Content Against Hostile Attacks”,        Graunke, Gary L.    -   4. European Patent Application No. ep 1 947 584 a1, Jul. 23,        2007, “Obfuscating Computer Program Code”, Bjorn, Johansson.    -   5. International Application No. PCT/CA02/000754, Nov. 28, 2002,        “Tamper Resistant Software Encoding and Analysis”, Chow, Stanley        T.    -   6. International Application No. PCT/CA08/000333, Aug. 28, 2008,        “System and Method for Interlocking to Protect Software-Mediated        Program and Device Behaviours”, Johnson, Harold J.    -   7. International Application No. PCT/CA08/000331, Feb. 21, 2008,        “The System and Method for Interlocking to Protect        Software-Mediated Program and Device Behaviours”, Johnson,        Harold Joseph.    -   8. U.S. Patent Application Publication US 2003/0163718, Aug. 28,        2003, “Tamper Resistant Software-Mass Data Encoding”, Johnson,        Harold J.    -   9. U.S. Patent Application Publication US 2003/0221121, Nov. 27,        2003, “Tamper Resistant Software Encoding”, Chow, Stanley T.    -   10. U.S. Pat. No. 6,594,761, Jul. 15, 2003, “Tamper Resistant        Software Encoding”, Chow, Stanley T.    -   11. U.S. Pat. No. 6,770,114, Aug. 17, 2004, “Tamper Resistant        Software Control Flow Encoding”, Chow, Stanley T,    -   12. U.S. Pat. No. 6,842,862, Jan. 11, 2005, “Tamper Resistant        Software Encoding”, Chow, Stanley T.    -   13. U.S. Pat. No. 7,325,141, Jan. 29, 2008, “Method and System        for Secure Access”, Chow, Stanley T.    -   14. U.S. Pat. No. 7,350,085, Mar. 25, 2008, “Tamper Resistant        Software-Mass Data Encoding”, Johnson, Harold J.    -   15. U.S. Patent Application Publication No. US 2003/0163718,        Aug. 28, 2003, “Tamper Resistant Software-Mass Data Encoding”,        Johnson, Harold J.    -   16. International Application No. PCT/CA99/00633, Feb. 24, 2000,        “Internet Authentication Technology”, Chow, Stanley T.    -   17. International Application No. PCT/US05/012835, Nov. 24,        2005, “System and Method for Creating Tamper-Resistant Code”,        Batton, James D.    -   18. International Application No. PCT/US06/026932, Jan. 18,        2007, “Method and System for Software Protection Using Binary        Encoding”, Davidson, Jack.    -   19. U.S. Patent Application Publication No. US 2005/0246554,        Nov. 3, 2005, “System and Method for Creating Tamper-Resistant        Code”, Batson, James D.    -   20. U.S. Patent Application Publication US 2006/0048223, Mar. 2,        2006, “Method and System for Providing Tamper-Resistant        Software”, Lee, Michael Chin-To.    -   21. U.S. Patent Application Publication US 2006/0107070, May 18,        2006, “Method and System for Secure Computational Outsourcing        and Disguise”, Rice, John R.    -   22. U.S. Pat. No. 6,957,341, Oct. 18, 2005, “Method and System        for Secure Computational Outsourcing and Disguise”, Rice, John        R.    -   23. U.S. Pat. No. 6,006,328, Dec. 21, 1999, “Computer Software        Authentication, Protection and Security System”, Drake,        Christopher N.    -   24. U.S. Pat. No. 6,941,463, Sep. 6, 2005, “Secure Computational        Outsourcing Techniques”, Atallah, Mikhail J.    -   25. U.S. Patent Application Publication US 2006/0031686, Feb. 9,        2006, “Method and System for Tamperproofing Software”, Atallah,        Mikhail J.    -   26. U.S. Pat. No. 8,842,862, Jan. 11, 2005, “Tamper Resistant        Software Encoding”, Chow, Stanley T.    -   27. Dec. 31, 2007, “Protecting Media Players via Software        Dynamic Translation”, Hiser, Jason D.    -   28. “Strata: A Software Dynamic Translation Infrastructure”,        Scott, Kevin and Davidson, Jack.

The following references as listed below and throughout this documentare hereby incorporated by reference herein in their entirety:

[1] D. J. Albert and S. P. Morse. Combatting software piracy byencryption and key management. Computer, 17(4):68-73, 1984.

[2] D. Aucsmith. Tamper resistant software: an implementation. InProceedings of the First International Workshop on Information Hiding,pages 317-333. Springer-Verlag London, UK, 1996.

[3] O. Billet, H. Gilbert, and C. Ech-Chatbi. Cryptanalysis of a whitebox AES implementation, 2004.

[4] H. Chang and M. J. Atallah. Protecting software code by guards.Proceedings of the ACM Workshop on Security and Privacy in DigitalRights Management, pages 160-175, 2000.

[5] S. Chow, P. Eisen, H. Johnson, and P. C. van Oorschot. White-boxcryptography and an AES implementation. Proceedings of the NinthWorkshop on Selected Areas in Cryptography (SAC 2002), 2002.

-   -   [6] F. B. Cohen. Operating system protection through program        evolution. Computers and Security, 12(6):565-584, 1993.

[7] C. Collberg, C. Thomborson, and D. Low. A taxonomy of obfuscatingtransformations. University of Auckland Technical Report, 170, 1997.

[8] C. Collberg, C. Thomborson, and D. Low. Manufacturing cheap,resilient, and stealthy opaque constructs. In Proceedings of the 25thACM SIGPLAN-SIGACT Symposium on Principles of Programming Languages,pages 184-196. ACM Press New York, N.Y., USA, 1998.

[9] C S Collberg and C. Thomborson. Watermarking, tamper-proofing, andobfuscation-tools for software protection. IEEE Transactions on SoftwareEngineering, 28(8):735-746, 2002.

[10] J. T. Giffin, M. Christodorescu, and L. Kruger. Strengtheningsoftware self-checksumming via self-modifying code. Proceedings of the21st Annual Computer Security Applications Conference, pages 23-32,2005.

[11] Jason D. Hiser, Daniel Williams, Adrian Filipi, Jack W. Davidson,and Bruce Childers. Evaluating fragment creation policies for SDTsystems. In Proceedings of the Second International Conference onVirtual Execution Environments, Ottawa, Canada, June 2006. ACM Press.

[12] B. Horne, L. R. Matheson, C. Sheehan, and R. E. Tarjan. Dynamicself-checking techniques for improved tamper resistance. Digital RightsManagement Workshop, pages 141-159, 2001.

[13] Wei Hu, Jason D. Hiser, Daniel Williams, Adrian Filipi, Jack W.Davidson, David Evans, John C. Knight, Anh Nguyen-Tuong, and JonathanRowanhill. Secure and practical defense against code-injection attacksusing software dynamic translation. In Proceedings of the 2ndInternational Conference on Virtual Execution Environments, pages 2-12.ACM Press New York, N.Y., USA, 2006.

[14] M. Jakobsson and M. Reiter. Discouraging software piracy usingsoftware aging. Digital Rights Management Workshop, pages 1-12, 2001.

[15] Y. Kanzaki, A. Monden, M. Nakamura, and K. Matsumoto. Exploitingself-modification mechanism for program protection. Proceedings of the27th Annual International Computer Software and Applications Conference,pages 170-179, 2003.

[16] Gaurav S. Kc, Angelos D. Keromytis, and Vassilis Prevelakis.Countering code-injection attacks with instruction-set randomization. InProceedings of the 10th ACM Conference on Computer and CommunicationsSecurity, pages 272-280, New York, N.Y., USA, 2003. ACM Press.

[17] C. Kruegel, W. Robertson, F. Valeur, and G. Vigna. Staticdisassembly of obfuscated binaries. In Proceedings of the 13th USENIXSecurity Symposium, Berkeley, Calif., USA, 2004. USENIX Association.

[18] B. A. Kuperman, C. E. Brodley, H. Ozdoganoglu, T N Vijaykumar, andA. Jalote. Detection and prevention of stack buffer overflow attacks.Communications of the ACM, 48(11):50-56, 2005.

[19] D. Lie, C. Thekkath, M. Mitchell, P. Lincoln, D. Boneh, J.Mitchell, and M. Horowitz. Architectural support for copy and tamperresistant software. ACM SIGPLAN Notices, 35(11):168-177, 2000.

[20] H. E. Link and W. D. Neumann. Clarifying obfuscation: Improving thesecurity of white-box encoding. Sandia National Laboratories,Albuquerque, N.M., downloaded from eprint.iacr.org/2004/025.pdf, 2004.

[21] C. Linn and S. Debray. Obfuscation of executable code to improveresistance to static disassembly. Proceedings of the 10th ACM conferenceon Computer and Communications Security, pages 290-299, 2003.

[22] C. Linn, S. Debray, and J. Kececioglu. Enhancing softwaretamper-resistance via stealthy address computations. Proceedings of the19th Annual Computer Security Applications Conference (ACSAC 2003),2003.

[23] M. Madou, B. Anckaert, P. Moseley, S. Debray, B. De Sutter, and K.De Bosschere. Software protection through dynamic code mutation.Proceedings of the 6th International Workshop on Information SecurityApplications (WISA, pages 194-206, 2005.

[24] T. Maude and D. Maude. Hardware protection against software piracy.Communications of the ACM, 27(9):950-959, 1984.

[25] G. Naumovich and N. Memon. Preventing piracy, reverse engineering,and tampering. Computer, 36(7):64-71, 2003.

[26] Kevin Scott and Jack Davidson. Strata: A software dynamictranslation infrastructure. In IEEE Workshop on Binary Translation,September 2001.

[27] A. Seshadri, M. Luk, E. Shi, A. Perrig, L. van Doom, and P. Khosla.Pioneer: verifying code integrity and enforcing untampered codeexecution on legacy systems. Proceedings of the 20th ACM symposium onOperating Systems Principles, pages 1-16, 2005.

[28] G. E. Suh, D. Clarke, B. Gassend, M. van Dijk, and S. Devadas.AEGIS: architecture for tamper-evident and tamper-resistant processing.Proceedings of the 17th Annual International Conference onSupercomputing, pages 160-171, 2003.

[29] Joan Daemen and Vincent Rijmen, “The Design of Rijndael: AES—TheAdvanced Encryption Standard.” Springer-Verlag, 2002.

[30] D. L. C. Thekkath, M. Mitchell, P. Lincoln, D. Boneh, J. Mitchell,and M. Horowitz. Architectural support for copy and tamper resistantsoftware. ACM SIGARCH Computer Architecture News, 28(5):168-177, 2000.

[31] S K Udupa, S K Debray, and Matias Madou. Deobfuscation: Reverseengineering obfuscated code. Reverse Engineering, 12th WorkingConference on, pages 45-54, 2005.

[32] P. C. van Oorschot, A. Somayaji, and G. Wurster. Hardware-assistedcircumvention of self-hashing software tamper resistance. IEEETransactions on Dependable and Secure Computing, 2(2):82-92, 2005.

[33] C. Wang, J. Hill, J. Knight, and J. Davidson. Software tamperresistance: Obstructing static analysis of programs. University ofVirginia, Charlottesville, Va., 2000.

[34] G. Wurster, P C van Oorschot, and A. Somayaji. A generic attack onchecksumming-based software tamper resistance. Proceedings of the 2005IEEE Symposium on Security and Privacy, pages 127-138, 2005.

Unless clearly specified to the contrary, there is no requirement forany particular described or illustrated activity or element, anyparticular sequence or such activities, any particular size, speed,material, duration, contour, dimension or frequency, or any particularlyinterrelationship of such elements. Moreover, any activity can berepeated, any activity can be performed by multiple entities, and/or anyelement can be duplicated. Further, any activity or element can beexcluded, the sequence of activities can vary, and/or theinterrelationship of elements can vary. It should be appreciated thataspects of the present invention may have a variety of sizes, contours,shapes, compositions and materials as desired or required.

In summary, while the present invention has been described with respectto specific embodiments, many modifications, variations, alterations,substitutions, and equivalents will be apparent to those skilled in theart. The present invention is not to be limited in scope by the specificembodiment described herein. Indeed, various modifications of thepresent invention, in addition to those described herein, will beapparent to those of skill in the art from the foregoing description andaccompanying drawings. Accordingly, the invention is to be considered aslimited only by the spirit and scope of the following claims, includingall modifications and equivalents.

Still other embodiments will become readily apparent to those skilled inthis art from reading the above-recited detailed description anddrawings of certain exemplary embodiments. It should be understood thatnumerous variations, modifications, and additional embodiments arepossible, and accordingly, all such variations, modifications, andembodiments are to be regarded as being within the spirit and scope ofthis application. For example, regardless of the content of any portion(e.g., title, field, background, summary, abstract, drawing figure,etc.) of this application, unless clearly specified to the contrary,there is no requirement for the inclusion in any claim herein or of anyapplication claiming priority hereto of any particular described orillustrated activity or element, any particular sequence of suchactivities, or any particular interrelationship of such elements.Moreover, any activity can be repeated, any activity can be performed bymultiple entities, and/or any element can be duplicated. Further, anyactivity or element can be excluded, the sequence of activities canvary, and/or the interrelationship of elements can vary. Unless clearlyspecified to the contrary, there is no requirement for any particulardescribed or illustrated activity or element, any particular sequence orsuch activities, any particular size, speed, material, dimension orfrequency, or any particularly interrelationship of such elements.Accordingly, the descriptions and drawings are to be regarded asillustrative in nature, and not as restrictive. Moreover, when anynumber or range is described herein, unless clearly stated otherwise,that number or range is approximate. When any range is described herein,unless clearly stated otherwise, that range includes all values thereinand all sub ranges therein. Any information in any material (e.g., aUnited States/foreign patent, United States/foreign patent application,book, article, etc.) that has been incorporated by reference herein, isonly incorporated by reference to the extent that no conflict existsbetween such information and the other statements and drawings set forthherein. In the event of such conflict, including a conflict that wouldrender invalid any claim herein or seeking priority hereto, then anysuch conflicting information in such incorporated by reference materialis specifically not incorporated by reference herein.

1. A computer method of increasing the tamper-resistance and/orobscurity of computer software code, said method comprising: preparingthe computer software code for execution in a designated executionenvironment for making it difficult to execute the computer softwarecode independently from the designated execution environment, whereinsaid preparation comprises applying one or more computer softwarepreparation transformations to the computer software code; and preparingthe execution environment so that it impedes execution of computersoftware code in the execution environment except for a designatedcomputer software code.
 2. (canceled)
 3. The method of claim 1, whereinsaid computer software preparation transformation comprises encryptingthe computer software code using a plurality of keys hidden within theexecution environment and/or prepared software code. 4-5. (canceled) 6.The method of claim 1, wherein said computer software preparationtransformation further comprises adding additional codes and/or data tothe computer software to verify the integrity of at least one of theexecution environment and the prepared software code.
 7. (canceled) 8.The method of claim 1, wherein said computer software preparationtransformation further comprises altering the computer software codesuch that proper execution is difficult without undoing the alterations,said altering including at least one of altering: constant operands;program control flow; program data layout; data initializationinformation; instruction encoding; or file format. 9-10. (canceled) 11.The method of claim 1, wherein said execution preparation comprisesapplying one or more preparation execution environment transformationsto the execution environment computer software code, and wherein saidexecution environment preparation transformation comprises encryptingsome or all of the execution environment, using a plurality of keyshidden within the execution environment and/or prepared software code.12-14. (canceled)
 15. The method of claim 1, wherein said executionenvironment preparation transformation further comprises addingadditional codes and/or data to the computer software executionenvironment to verify the integrity of at least one of the computersoftware code and the prepared execution environment.
 16. (canceled) 17.The method of claim 1, wherein said method further comprises applyingexecution transformations to both of the prepared computer software codeand the prepared execution environment during execution of a computersoftware code to improve tamper resistance and/or obscurity in adesignated execution environment, wherein said execution transformationcomprises the execution environment changing the layout of computersoftware code data, the computer software code data being one of atleast data used for the execution environment or data to execute thecomputer software code or data to execute prepared software code. 18-19.(canceled)
 20. The method of claim 17, wherein said executiontransformation comprises the execution environment using conditionsgenerated during execution, whereby said conditions are difficult toprogrammatically decipher to assist in the tamper-resistance and/orobscurity transforms.
 21. The method of claim 17, wherein the executiontransformations include at least one of relocating operational locationsto increase the difficulty of determining operation locations for makingoperation's locations difficult to determine, and rearranging,eliminating or adding execution flow for making execution flow and/orcontrol flow difficult to determine.
 22. (canceled)
 23. The method ofclaim 17, wherein the execution transformations include at least one ofinserting additional software code and/or data for making the softwarecode operations difficult to determine, and inserting incorrect codesthat are intentionally similar to other correct software codes.
 24. Themethod of claim 17, wherein the execution transformations include atleast one of inserting operations that cannot be feasibly executed, butappear as though execution is possible, and randomizing operation order.25-26. (canceled)
 27. The method of claim 17, wherein the executiontransformations insert dynamically operations into the execution toverify the integrity of computer software code and/or data, wherein thecomputer software code and/or data comprises at least one of: preparedcomputer software code and/or data, unprepared computer software codeand/or data, prepared execution environment code and/or data, unpreparedexecution environment code and/or data, and or previously transformedcomputer software code and/or data, or any combinations thereof. 28.(canceled)
 29. The method of claim 17, wherein said one or moreexecution transformations comprises at least one of: control flowflattening, guards, disassembly resistance, self checksumming codes,dynamic disassembly resistance, control flow obfuscations, ABItransforms, API transforms, sequence transforms, calling conventiontransforms and or data transform, or any combination thereof.
 30. Themethod of claim 17, wherein the execution environment continuouslyperforms the execution transformations, the continuous executioncomprising a plurality of encryption/decryption keys.
 31. (canceled) 32.The method of claim 17, wherein said execution environment comprises atleast one of: software dynamic translation (SDT), virtual machine (VM),Java VM, Strata VM, program simulators, program emulators, and orvirtualization systems, or any combinations thereof.
 33. The method ofclaim 17, wherein said computer software code comprises at least one of:binary, byte code, program source, program assembly, program scripts,machine language, and or program intermediate formats, or anycombination thereof and wherein said program scripts comprises at leastone of the following: Perl, PHP, python, CGI, Java, Java Script, ASPscript, MySQL, Borne shell, bash, tcsh, and or csh, or any combinationsthereof. 34-59. (canceled)
 60. A computer method of increasing thetamper-resistance and/or obscurity of computer software code, saidmethod comprising: applying execution transformations during executionof a computer software code to improve tamper resistance and/orobscurity, wherein said preparation comprises applying one or morecomputer software preparation transformations to the computer softwarecode; and preparing the computer software code for execution in adesignated execution environment for making it difficult to execute thecomputer software code independently from the designated executionenvironment.
 61. The method of claim 60, wherein said executiontransformation further comprises the execution environment changing thelayout of computer software code data, the computer software code databeing at least one of data used for the execution environment or data toexecute the computer software code or data to execute prepared softwarecode.
 62. (canceled)
 63. The method of claim 60, wherein said executiontransformation further comprises the execution environment usingconditions generated during execution, whereby said conditions aredifficult to programatically decipher to assist in the tamper-resistanceand/or obscurity transforms.
 64. The method of claim 60, wherein theexecution transformations include at least one of relocating operationallocations to increase the difficulty of determining operation locationsfor making operation's locations difficult to determine, andrearranging, eliminating or adding execution flow for making executionflow and/or control flow difficult to determine.
 65. (canceled)
 66. Themethod of claim 60, wherein the execution transformations include atleast one of inserting additional software code and/or data for makingthe software code operations difficult to determine, and insertingincorrect codes that are intentionally similar to other correct softwarecodes.
 67. The method of claim 60, wherein the execution transformationsinclude at least one of inserting operations that cannot be feasiblyexecuted, but appear as though execution is possible, and randomizingoperation order.
 68. (canceled)
 69. (canceled)
 70. The method of claim60, wherein the execution transformations insert dynamically operationsinto the execution to verify the integrity of computer software codeand/or data.
 71. The method of claim 70, wherein the computer softwarecode and/or data comprises at least one of: prepared computer softwarecode and/or data, unprepared computer software code and/or data,prepared execution environment code and/or data, unprepared executionenvironment code and/or data, or previously transformed computersoftware code and/or data, or any combinations thereof.
 72. The methodof claim 60, wherein said one or more execution transformationscomprises at least one of: control flow flattening, guards, disassemblyresistance, self checksumming codes, dynamic disassembly resistance,control flow obfuscations, ABI transforms, API transforms, sequencetransforms, calling convention transforms or data transform, or anycombination thereof.
 73. The method of claim 60, wherein the executionenvironment continuously performs the execution transformations, thecontinuous execution comprises a plurality of encryption/decryptionkeys.
 74. (canceled)
 75. The method of claim 60, wherein said executionenvironment comprises at least one of: software dynamic translation(SDT), virtual machine (VM), Java VM, Strata VM, program simulators,program emulators, or virtualization systems, or any combinationsthereof.
 76. The method of claim 60, wherein said computer software codecomprises at least one of: binary, byte code, program source, programassembly, program scripts, machine language, or program intermediateformats, or any combination thereof, and wherein said program scriptscomprises at least one of the following: Perl, PHP, python, CGI, Java,Java Script, ASP script, MySQL, Borne shell, bash, tcsh, or csh, or anycombinations thereof. 77-79. (canceled)
 80. The method of claim 60,wherein said computer software preparation transformation comprisesencrypting the computer software code using a plurality of keys hiddenwithin the execution environment and/or prepared software code. 81.(canceled)
 82. (canceled)
 83. The method of claim 60, wherein saidcomputer software preparation transformation comprises at least one ofadding additional codes and/or data to the computer software to verifythe integrity of at least one of the execution environment, and theprepared software code.
 84. (canceled)
 85. The method of claim 83,wherein said computer software preparation transformation comprisesaltering the computer software code such that proper execution isdifficult without undoing the alterations, wherein said alteringincludes at least one of: altering constant operands, program controlflow, program data layout, data initialization information, instructionencoding, or file format, or any combination thereof.
 86. (canceled) 87.The method of claim 60, wherein said execution transformation comprisesinterpreting said preparation transformations on the prepared softwarecodes. 88-125. (canceled)
 126. A computer program product comprising acomputer useable medium having computer program logic for enabling atleast one processor in a computer system to increase thetamper-resistance and/or obscurity of computer software code, saidcomputer logic comprising: preparing the computer software code forexecution in a designated execution environment for making it difficultto execute the computer software code independently from the designatedexecution environment, wherein said preparation comprises applying oneor more computer software preparation transformations to the computersoftware code; and preparing the execution environment so that itimpedes execution of computer software code in the execution environmentexcept for a designated computer software code.
 127. (canceled)
 128. Thecomputer program product of claim 126, wherein said computer softwarepreparation transformation comprises encrypting the computer softwarecode using a plurality of keys hidden within the execution environmentand/or prepared software code.
 129. (canceled)
 130. (canceled)
 131. Thecomputer program product of claim 126, wherein said computer softwarepreparation transformation further comprises adding additional codesand/or data to the computer software to verify the integrity of at leastone of the execution environment and the prepared software code. 132.(canceled)
 133. The computer program product of claim 131, wherein saidcomputer software preparation transformation further comprises alteringthe computer software code such that proper execution is difficultwithout undoing the alterations, said altering includes at least one ofaltering constant operands, program control flow, program data layout,data initialization information, instruction encoding, or file format,or any combination thereof.
 134. (canceled)
 135. (canceled)
 136. Thecomputer program product of claim 126, wherein said system comprisingapplying execution transformations to both of the prepared computersoftware code and the prepared execution environment during execution ofa computer software code to improve tamper resistance and/or obscurityin a designated execution environment. 137-165. (canceled)